feat: add support for headless rule config #258
Conversation
How to use the Graphite Merge QueueAdd the label 0-merge to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
camchenry
force-pushed
the
09-21-feat_add_support_for_headless_rule_config
branch
2 times, most recently
from
a943347 to
083a2ae
Compare
|
@camc314 I'd appreciate your early thoughts on this direction. I'd love to find a way to avoid rewriting every rule to be compatible with accepting JSON input. |
|
Sorry @auvred I should have pinged you too last night! You're much more familiar with Go than I am, so perhaps there is a more idiomatic way of handling this. With the current approach, we would need to manually (or have AI) write a function for every rule that allows accepting |
|
As stated in #51 (comment), the main issue is that Go structs don't allow expressing typescript-eslint options one-to-one. If I were doing this, I'd write (or try to find) a Go code generator that takes typescript-eslint meta.schema (JSON Schema) and generates a small, interface-based typed deserializer for each rule. |
|
Is there any update on progress towards the go struct/typescript-eslint option mapping? don't want to be pushy, just really looking forward to this so we can give it a spin! Thanks! |
|
@osdiab I've been busy with other things, but I am actively working on this again, so I hope to have it usable in oxlint in the next month or so. |
camchenry
force-pushed
the
09-21-feat_add_support_for_headless_rule_config
branch
7 times, most recently
from
5591d21 to
bcd476e
Compare
camchenry
force-pushed
the
09-21-feat_add_support_for_headless_rule_config
branch
2 times, most recently
from
d80a2b4 to
3344a06
Compare
Merge activity
|
- Towards #51 This is an initial pass at supporting rule configurations in headless mode. We currently do not pass any options along from `oxlint`, but this allows passing an `options` field in the headless payload with each rule which will get serialized and pass along to the rule. We will need to be careful about how we handle the configs and validate the input coming in. However, this should be a backwards compatible change since it only adds a new field to the existing payload. This uses `go-jsonschema` to generate the JSON deserialization code from a JSON Schema file, which makes adding or updating the supported options very easy. This reduces a lot of the maintenance for us and should make it quick to add support for configuration to all of the existing rules. To go along with that, there is a new CI workflow that validates the generated schema code matches what we expect (needs to be regenerated for any changes). For now, only the `no-floating-promises` rule is implemented, as it has some non-trivial options configuration. Most other rules should be simpler than this one.
graphite-app
bot
force-pushed
the
09-21-feat_add_support_for_headless_rule_config
branch
from
3344a06 to
8d8e029
Compare
graphite-app
bot
deleted the
09-21-feat_add_support_for_headless_rule_config
branch
This is an initial pass at supporting rule configurations in headless mode. We currently do not pass any options along from
oxlint, but this allows passing anoptionsfield in the headless payload with each rule which will get serialized and pass along to the rule. We will need to be careful about how we handle the configs and validate the input coming in. However, this should be a backwards compatible change since it only adds a new field to the existing payload.This uses
go-jsonschemato generate the JSON deserialization code from a JSON Schema file, which makes adding or updating the supported options very easy. This reduces a lot of the maintenance for us and should make it quick to add support for configuration to all of the existing rules. To go along with that, there is a new CI workflow that validates the generated schema code matches what we expect (needs to be regenerated for any changes).For now, only the
no-floating-promisesrule is implemented, as it has some non-trivial options configuration. Most other rules should be simpler than this one.